JavaScript Module Entity Patterns: Et dybdegående kig på domæneobjektmodellering

I softwareudviklingens verden, især inden for det dynamiske og evigt udviklende JavaScript-økosystem, prioriterer vi ofte hastighed, frameworks og funktioner. Vi bygger komplekse brugergrænseflader, forbinder til utallige API'er og implementerer applikationer i et svimlende tempo. Men i dette hastværk forsømmer vi nogle gange selve kernen af vores applikation: forretningsdomænet. Dette kan føre til det, der ofte kaldes "Big Ball of Mud" – et system, hvor forretningslogikken er spredt, data er ustrukturerede, og en simpel ændring kan udløse en kaskade af uforudsete fejl.

Det er her, domæneobjektmodellering kommer ind. Det er praksissen med at skabe en rig, udtryksfuld model af det problemområde, du arbejder i. Og i JavaScript er Module Entity Pattern en kraftfuld, elegant og framework-agnostisk måde at opnå dette på. Denne omfattende guide vil føre dig gennem teori, praksis og fordelene ved dette mønster, hvilket giver dig mulighed for at bygge mere robuste, skalerbare og vedligeholdelsesvenlige applikationer.

Hvad er domæneobjektmodellering?

Før vi dykker ned i selve mønstret, lad os præcisere vores begreber. Det er afgørende at skelne dette koncept fra browserens Document Object Model (DOM).

• Domæne: I software er 'domænet' det specifikke emneområde, som brugerens forretning tilhører. For en e-handelsapplikation inkluderer domænet koncepter som Produkter, Kunder, Ordrer og Betalinger. For en social medieplatform inkluderer det Brugere, Opslag, Kommentarer og Likes.
• Domæneobjektmodellering: Dette er processen med at skabe en softwaremodel, der repræsenterer entiteterne, deres adfærd og deres relationer inden for det forretningsdomæne. Det handler om at oversætte virkelige koncepter til kode.

En god domænemodel er ikke bare en samling af databeholdere. Det er en levende repræsentation af dine forretningsregler. Et Order-objekt skal ikke bare indeholde en liste over elementer; det skal vide, hvordan man beregner sin total, hvordan man tilføjer et nyt element, og om det kan annulleres. Denne indkapsling af data og adfærd er nøglen til at bygge en robust applikationskerne.

Det fælles problem: Anarki i "model"-laget

I mange JavaScript-applikationer, især dem der vokser organisk, er 'model'-laget ofte en eftertanke. Vi ser ofte dette anti-mønster:

            
// Et sted i en API-controller eller service...
async function createUser(req, res) {
  const { email, password, firstName, lastName } = req.body;

  // Forretningslogik og validering er spredt her
  if (!email || !email.includes('@')) {
    return res.status(400).send({ error: 'A valid email is required.' });
  }

  if (!password || password.length < 8) {
    return res.status(400).send({ error: 'Password must be at least 8 characters.' });
  }

  const user = {
    email: email.toLowerCase(),
    password: await hashPassword(password), // En hjælpefunktion
    fullName: `${firstName} ${lastName}`, // Logik for afledte data er her
    createdAt: new Date()
  };

  // Hvad er `user` nu? Det er bare et simpelt objekt.
  // Intet forhindrer en anden udvikler i at gøre dette senere:
  // user.email = 'an-invalid-email';
  // user.password = 'short';

  await db.users.insert(user);
  res.status(201).send(user);
}

            

              
                Copy
              
            
          

Denne tilgang præsenterer flere kritiske problemer:

• Ingen enkelt sandhedskilde: Reglerne for, hvad der udgør en gyldig 'bruger', er defineret inde i denne ene controller. Hvad hvis en anden del af systemet skal oprette en bruger? Kopierer du logikken? Dette fører til inkonsekvens og fejl.
• Anæmisk domænemodel: user-objektet er blot en 'dum' databeholder. Det har ingen adfærd og ingen selvbevidsthed. Al logik, der opererer på det, lever eksternt.
• Lav samhørighed: Logikken for at oprette en brugers fulde navn er blandet med API-forespørgsels-/svarhåndtering og adgangskodehashning.
• Svært at teste: For at teste brugeroprettelseslogikken skal du mocke HTTP-anmodninger og -svar, databaser og hashing-funktioner. Du kan ikke bare teste 'bruger'-konceptet isoleret.
• Implikitte kontrakter: Resten af applikationen skal bare 'antage', at ethvert objekt, der repræsenterer en bruger, har en bestemt form, og at dets data er gyldige. Der er ingen garantier.

Løsningen: JavaScript Module Entity-mønstret

Modul-entitetsmønstret adresserer disse problemer ved at bruge et standard JavaScript-modul (én fil) til at definere alt om et enkelt domænekoncept. Dette modul bliver den definitive sandhedskilde for den pågældende entitet.

En modul-entitet eksponerer typisk en fabriksfunktion. Denne funktion er ansvarlig for at oprette en gyldig instans af entiteten. Objektet, den returnerer, er ikke bare data; det er et rigt domæneobjekt, der indkapsler sine egne data, validering og forretningslogik.

Nøglekarakteristika ved en modul-entitet

• Indkapsling: Den samler data og de funktioner, der opererer på disse data.
• Validering ved grænsen: Den sikrer, at det er umuligt at oprette en ugyldig entitet. Den beskytter sin egen tilstand.
• Klar API: Den eksponerer et rent, intentionelt sæt funktioner (en offentlig API) til interaktion med entiteten, mens den skjuler interne implementeringsdetaljer.
• Uforanderlighed: Den producerer ofte uforanderlige eller skrivebeskyttede objekter for at forhindre utilsigtede tilstandsændringer og sikre forudsigelig adfærd.
• Portabilitet: Den har nul afhængigheder af frameworks (som Express, React) eller eksterne systemer (som databaser, API'er). Det er ren forretningslogik.

Kernekkomponenter i en modul-entitet

Lad os genopbygge vores User-koncept ved hjælp af dette mønster. Vi opretter en fil, user.js (eller user.ts for TypeScript-brugere), og bygger den trin for trin.

1. Fabriksfunktionen: Din objektkonstruktør

I stedet for klasser bruger vi en fabriksfunktion (f.eks. buildUser). Fabrikker tilbyder stor fleksibilitet, undgår at kæmpe med this-nøgleordet og gør privat tilstand og indkapsling mere naturlig i JavaScript.

Vores mål er at skabe en funktion, der tager rå data og returnerer et velformet, pålideligt brugerobjekt.

            
// fil: /domain/user.js

export default function buildMakeUser() {
  // Denne indre funktion er den faktiske fabrik.
  // Den har adgang til alle afhængigheder, der er sendt til buildMakeUser, hvis nødvendigt.
  return function makeUser({
    id = generateId(), // Lad os antage en funktion til at generere et unikt ID
    firstName,
    lastName,
    email,
    passwordHash,
    createdAt = new Date()
  }) {
    // ... validering og logik kommer her ...

    const user = {
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => email,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt
    };

    // Bruger Object.freeze til at gøre objektet uforanderligt.
    return Object.freeze(user);
  }
}

            

              
                Copy
              
            
          

Bemærk et par ting her. Vi bruger en funktion, der returnerer en funktion (en højere-ordens funktion). Dette er et kraftfuldt mønster til at injicere afhængigheder, som en unik ID-generator eller et validatorbibliotek, uden at koble entiteten til en specifik implementering. For nu holder vi det simpelt.

2. Datavalidering: Vægteren ved porten

En entitet skal beskytte sin egen integritet. Det skal være umuligt at oprette en User i en ugyldig tilstand. Vi tilføjer validering direkte inde i fabriksfunktionen. Hvis dataene er ugyldige, skal fabriksfunktionen kaste en fejl, der tydeligt angiver, hvad der er galt.

            
// fil: /domain/user.js

export default function buildMakeUser({ Id, isValidEmail, hashPassword }) {
  return function makeUser({
    id = Id.makeId(),
    firstName,
    lastName,
    email,
    password, // Vi tager nu et almindeligt password og håndterer det internt
    createdAt = new Date()
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Bruger skal have et gyldigt id.');
    }
    if (!firstName || firstName.length < 2) {
      throw new Error('Fornavn skal være mindst 2 tegn langt.');
    }
    if (!lastName || lastName.length < 2) {
      throw new Error('Efternavn skal være mindst 2 tegn langt.');
    }
    if (!email || !isValidEmail(email)) {
      throw new Error('Bruger skal have en gyldig e-mailadresse.');
    }
    if (!password || password.length < 8) {
      throw new Error('Adgangskode skal være mindst 8 tegn langt.');
    }

    // Datanormalisering og transformation sker her
    const passwordHash = hashPassword(password); 
    const normalizedEmail = email.toLowerCase();

    return Object.freeze({
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => normalizedEmail,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt
    });
  }
}

            

              
                Copy
              
            
          

Nu skal enhver del af vores system, der ønsker at oprette en User, gå gennem denne fabrik. Vi får garanteret validering hver eneste gang. Vi har også indkapslet logikken for at hashe adgangskoden og normalisere e-mailadressen. Resten af applikationen behøver ikke at kende eller bekymre sig om disse detaljer.

3. Forretningslogik: Indkapsling af adfærd

Vores User-objekt er stadig lidt anæmisk. Det indeholder data, men det *gør* ikke noget. Lad os tilføje adfærd – metoder, der repræsenterer domænespecifikke handlinger.

            
// ... inde i makeUser-funktionen ...

    if (!password || password.length < 8) {
      // ...
    }

    const passwordHash = hashPassword(password);
    const normalizedEmail = email.toLowerCase();

    return Object.freeze({
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => normalizedEmail,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt,

      // Forretningslogik / Adfærd
      getFullName: () => `${firstName} ${lastName}`,
      
      // En metode, der beskriver en forretningsregel
      canVote: () => {
          // I nogle lande er stemmeretsalderen 18. Dette er en forretningsregel.
          // Lad os antage, at vi har en dateOfBirth-egenskab.
          const age = calculateAge(dateOfBirth);
          return age >= 18;
      }
    });
// ...

            

              
                Copy
              
            
          

getFullName-logikken er ikke længere spredt i en tilfældig controller; den tilhører selve User-entiteten. Enhver med et User-objekt kan nu pålideligt få det fulde navn ved at kalde user.getFullName(). Logikken er defineret én gang, ét sted.

Opbygning af et praktisk eksempel: Et simpelt e-handelssystem

Lad os anvende dette mønster på et mere sammenhængende domæne. Vi modellerer et Product, et OrderItem og en Order.

1. Modellering af Product-entiteten

Et produkt har et navn, en pris og nogle lageroplysninger. Det skal have et navn, og dets pris kan ikke være negativ.

            
// fil: /domain/product.js

export default function buildMakeProduct({ Id }) {
  return function makeProduct({
    id = Id.makeId(),
    name,
    description,
    price,
    stock = 0
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Produkt skal have et gyldigt ID.');
    }
    if (!name || name.trim().length < 2) {
      throw new Error('Produktnavn skal være mindst 2 tegn.');
    }
    if (isNaN(price) || price <= 0) {
      throw new Error('Produkt skal have en pris større end nul.');
    }
    if (isNaN(stock) || stock < 0) {
      throw new Error('Lagerbeholdning skal være et ikke-negativt tal.');
    }

    return Object.freeze({
      getId: () => id,
      getName: () => name,
      getDescription: () => description,
      getPrice: () => price,
      getStock: () => stock,
      
      // Forretningslogik
      isAvailable: () => stock > 0,
      
      // En metode, der ændrer tilstand ved at returnere en ny instans
      reduceStock: (amount) => {
        if (amount > stock) {
          throw new Error('Ikke nok lagerbeholdning til rådighed.');
        }
        // Returnerer et NYT produktobjekt med den opdaterede lagerbeholdning
        return makeProduct({ id, name, description, price, stock: stock - amount });
      }
    });
  }
}

            

              
                Copy
              
            
          

Bemærk metoden reduceStock. Dette er et afgørende koncept relateret til uforanderlighed. I stedet for at ændre stock-egenskaben på det eksisterende objekt, returnerer den en *ny* Product-instans med den opdaterede værdi. Dette gør tilstandsændringer eksplicitte og forudsigelige.

2. Modellering af Order-entiteten (Aggregeringsroden)

En Order er mere kompleks. Det er det, Domain-Driven Design (DDD) kalder en "Aggregate Root." Det er en entitet, der administrerer andre, mindre objekter inden for sin grænse. En Order indeholder en liste over OrderItems. Du tilføjer ikke et produkt direkte til en ordre; du tilføjer en OrderItem, som indeholder et produkt og en mængde.

            
// fil: /domain/order.js

export const ORDER_STATUS = {
  PENDING: 'PENDING',
  PAID: 'PAID',
  SHIPPED: 'SHIPPED',
  CANCELLED: 'CANCELLED'
};

export default function buildMakeOrder({ Id, validateOrderItem }) {
  return function makeOrder({
    id = Id.makeId(),
    customerId,
    items = [],
    status = ORDER_STATUS.PENDING,
    createdAt = new Date()
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Ordre skal have et gyldigt ID.');
    }
    if (!customerId) {
      throw new Error('Ordre skal have et kunde-ID.');
    }

    let orderItems = [...items]; // Opret en privat kopi til styring

    return Object.freeze({
      getId: () => id,
      getCustomerId: () => customerId,
      getItems: () => [...orderItems], // Returner en kopi for at forhindre ekstern ændring
      getStatus: () => status,
      getCreatedAt: () => createdAt,
      
      // Forretningslogik
      calculateTotal: () => {
        return orderItems.reduce((total, item) => {
          return total + (item.getPrice() * item.getQuantity());
        }, 0);
      },

      addItem: (item) => {
        // validateOrderItem er en funktion, der sikrer, at elementet er en gyldig OrderItem-entitet
        validateOrderItem(item);

        // Forretningsregel: forhindr tilføjelse af dubletter, bare øg antallet
        const existingItemIndex = orderItems.findIndex(i => i.getProductId() === item.getProductId());

        if (existingItemIndex > -1) {
          const newQuantity = orderItems[existingItemIndex].getQuantity() + item.getQuantity();
          // Her ville du opdatere mængden på det eksisterende element
          // (Dette kræver, at elementer er mutable eller har en opdateringsmetode)
        } else {
          orderItems.push(item);
        }
      },

      markPaid: () => {
        if (status !== ORDER_STATUS.PENDING) {
          throw new Error('Kun afventende ordrer kan markeres som betalte.');
        }
        // Returner en ny Order-instans med den opdaterede status
        return makeOrder({ id, customerId, items: orderItems, status: ORDER_STATUS.PAID, createdAt });
      }
    });
  }
}

            

              
                Copy
              
            
          

Denne Order-entitet håndhæver nu komplekse forretningsregler:

• Den administrerer sin egen liste af elementer.
• Den ved, hvordan man beregner sin egen total.
• Den håndhæver tilstandsovergange (f.eks. kan du kun markere en PENDING ordre som PAID).

Forretningslogikken for ordrer er nu pænt indkapslet i dette modul, testbar isoleret og genanvendelig på tværs af hele din applikation.

Avancerede mønstre og overvejelser

Uforanderlighed: Hjørnestenen i forudsigelighed

Vi har berørt uforanderlighed. Hvorfor er det så vigtigt? Når objekter er uforanderlige, kan du sende dem rundt i din applikation uden frygt for, at en fjern funktion uventet vil ændre deres tilstand. Dette eliminerer en hel klasse af fejl og gør din applikations dataflow meget lettere at forstå.

Object.freeze() giver en overfladisk frysning. For entiteter med indlejrede objekter eller arrays (som vores Order), skal du være mere forsigtig. For eksempel, i order.getItems(), returnerede vi en kopi ([...orderItems]) for at forhindre kalderen i at skubbe elementer direkte ind i ordrens interne array.

For komplekse applikationer kan biblioteker som Immer gøre arbejdet med uforanderlige indlejrede strukturer meget lettere, men kerneprincippet forbliver: behandl dine entiteter som uforanderlige værdier. Når en ændring skal ske, skal du oprette en ny værdi.

Håndtering af asynkrone operationer og persistens

Du har måske bemærket, at vores entiteter er helt synkrone. De ved intet om databaser eller API'er. Dette er intentionalt og en stor styrke ved mønstret!

Entiteter bør ikke gemme sig selv. En entitets opgave er at håndhæve forretningsregler. Opgaven med at gemme data i en database tilhører et andet lag af din applikation, ofte kaldet et Service Layer, Use Case Layer eller Repository Pattern.

Sådan interagerer de:

            
// fil: /use-cases/create-user.js

// Dette use case afhænger af user entity factory og en databaseadgangsfunktion.
export default function makeCreateUser({ makeUser, usersDatabase }) {
  return async function createUser(userInfo) {
    // 1. Opret en gyldig domæneentitet. Dette trin validerer dataene.
    const user = makeUser(userInfo);

    // 2. Kontroller for forretningsregler, der kræver eksterne data (f.eks. unik e-mailadresse)
    const exists = await usersDatabase.findByEmail({ email: user.getEmail() });
    if (exists) {
      throw new Error('E-mailadresse er allerede i brug.');
    }

    // 3. Bevar entiteten. Databasen har brug for et simpelt objekt.
    const persisted = await usersDatabase.insert({
      id: user.getId(),
      firstName: user.getFirstName(),
      // ... og så videre
    });

    return persisted;
  }
}

            

              
                Copy
              
            
          

Denne adskillelse af ansvarsområder er kraftfuld:

• User-entiteten er ren, synkron og nem at enhedsteste.
• createUser use caset er ansvarlig for orkestrering og kan integrationstestes med en mock database.
• usersDatabase-modulet er ansvarligt for den specifikke databaseteori og kan testes separat.

Serialisering og deserialisering

Dine entiteter, med deres metoder, er rige objekter. Men når du sender data over et netværk (f.eks. i et JSON API-svar) eller gemmer det i en database, har du brug for en simpel datarepræsentation. Denne proces kaldes serialisering.

Et almindeligt mønster er at tilføje en toJSON()- eller toObject()-metode til din entitet.

            
// ... inde i makeUser-funktionen ...

    return Object.freeze({
      getId: () => id,
      // ... andre getters

      // Serialiseringsmetode
      toObject: () => ({
        id,
        firstName,
        lastName,
        email: normalizedEmail,
        createdAt
        // Bemærk, vi inkluderer ikke passwordHash
      })
    });

            

              
                Copy
              
            
          

Den omvendte proces, der tager simple data fra en database eller API og omdanner dem tilbage til en rig domæneentitet, er præcis, hvad din makeUser fabriksfunktion er til for. Dette er deserialisering.

Typing med TypeScript eller JSDoc

Selvom dette mønster fungerer perfekt i almindelig JavaScript, forbedrer tilføjelse af statiske typer med TypeScript eller JSDoc det betydeligt. Typer giver dig mulighed for formelt at definere 'formen' af din entitet, hvilket giver fremragende autokomplettering og kompileringstidscheck.

            
// fil: /domain/user.ts

// Definer entitetens offentlige grænseflade
export type User = Readonly<{
  getId: () => string;
  getFirstName: () => string;
  // ... osv
  getFullName: () => string;
}>;

// Fabriksfunktionen returnerer nu User-typen
export default function buildMakeUser(...) {
  return function makeUser(...): User {
    // ... implementering
  }
}

            

              
                Copy
              
            
          

De overordnede fordele ved modul-entitetsmønstret

Ved at anvende dette mønster opnår du en lang række fordele, der vokser i takt med, at din applikation udvides:

• Enkelt sandhedskilde: Forretningsregler og datavalidering er centraliserede og utvetydige. En ændring af en regel foretages præcis ét sted.
• Høj samhørighed, lav kobling: Entiteter er selvstændige og afhænger ikke af eksterne systemer. Dette gør din kodebase modulær og nem at refaktorere.
• Fremragende testbarhed: Du kan skrive simple, hurtige enhedstest for din mest kritiske forretningslogik uden at mocke hele verden.
• Forbedret udvikleroplevelse: Når en udvikler skal arbejde med en User, har de en klar, forudsigelig og selvbeskrivende API at bruge. Ikke mere gætteri om formen af simple objekter.
• Et fundament for skalerbarhed: Dette mønster giver dig en stabil, pålidelig kerne. Efterhånden som du tilføjer flere funktioner, frameworks eller UI-komponenter, forbliver din forretningslogik beskyttet og konsistent.

Konklusion: Byg en solid kerne til din applikation

I en verden af hurtigt bevægende frameworks og biblioteker er det let at glemme, at disse værktøjer er forbigående. De vil ændre sig. Det, der varer, er kernen i din forretningsdomæne. At investere tid i korrekt modellering af dette domæne er ikke kun en akademisk øvelse; det er en af de mest betydningsfulde langsigtede investeringer, du kan foretage i dit softwares sundhed og levetid.

JavaScript Module Entity Pattern giver en simpel, kraftfuld og indbygget måde at implementere disse ideer på. Det kræver ikke et tungt framework eller en kompleks opsætning. Det udnytter sprogets grundlæggende funktioner – moduler, funktioner og closures – til at hjælpe dig med at bygge en ren, robust og forståelig kerne til din applikation. Start med én nøgleentitet i dit næste projekt. Modeller dens egenskaber, valider dens oprettelse og giv den adfærd. Du vil tage det første skridt mod en mere robust og professionel softwarearkitektur.